This description relates to accessing distributed services in a network.
As shown in FIG. 1, the Internet 10 is a distributed system of networks, computers, and services. Within the Internet, clients 12 that need services provided by servers 28 at other locations use Internet Protocol (IP) addresses (which identify those other locations) to send service requests 26 to those servers. A typical IP address is a number that is either 32 bits long (under the IPv4 protocol) or 128 bits long (under the IPv6 protocol).
Although IP addresses are generally arbitrary values, they can be associated with domain/sub-domain names that have semantic meaning. For example, a sub-domain/domain name such as hdl.handle.net could be associated with an IP address. The system used in the Internet to associate domain/subdomain names with IP addresses is called the Domain Name System (DNS) 20. Although various naming and other identifier systems currently exist within the Internet, the example used for illustration is the DNS. In the following, the term domain name(s) is used to include sub-domain names at any level.
To reach the server 28 that provides the service called hdl.handle.net, a DNS client 12 (sometimes referred to as simply a client) can present a request 14 that includes the domain name handle.net to a “.net” registry 18 within the DNS. The registry contains entries 22 that associate IP addresses with corresponding domain names that end in “.net”. The registry finds the entry 23 for handle.net and the associated IP addresses for one or more Name Servers (NS) 25. A NS is part of the DNS and contains entries 27 that associate sub-domain names, such as those that end in handle.net, with IP addresses of corresponding servers. The registry returns the IP addresses of the NSs to the client.
The client then sends a resolution request 24 to the identified NSs 25 at the IP addresses provided by the registry. The resolution request 24 includes the sub-domain name hdl.handle.net. Each of the NSs is tried in turn until one of the NSs returns the IP address of hdl.handle.net 29 to the client. In other schemes, the NSs could be tried in parallel or using other selection criteria. The client uses that IP address to send its service request 26 to the hdl.handle.net server 28. Assuming that the hdl.handle.net server in fact resides at that IP address and is functioning, the server acts to satisfy 31 the client's request.
Each domain and sub-domain normally has more than one NS. This arrangement provides reliable access by the client to one of the NSs. However, there is no guarantee that the selected NS will provide the client an IP address for a server that is functioning and/or accessible by the client, because the NSs do not test the servers for availability before providing the IP address of the servers to the client, and they do not test connectivity between the client and the servers.
When a server malfunctions or its service is otherwise unavailable, various techniques have been developed to provide reliable equivalent access to the service by a client.
As shown in FIG. 2, one approach is to provide multiple redundant instances 28A, 28B, . . . , of a server for a given service. The servers may be located behind a load balancer 40 or a gateway. In this case, called a cluster, the IP address of the load balancer or gateway is the address that the DNS would typically associate with the sub-domain/domain name. When the client makes a service request 26 to the IP address specified for the cluster, the request is received by the load balancer or gateway and forwarded to one of the servers. The load balancer can distribute requests among the multiple servers to balance the load and, if one of the servers fails, direct all requests away from the failed server. If the entire cluster fails or becomes unavailable, the client is left without service from that cluster.
As shown in FIG. 3, in other approaches, the multiple redundant instances of the server 28 have different IP addresses and the domain name of a desired service can be resolved to any of those IP addresses. Each NS 25 maintains a list 32 of all IP addresses 34 of the redundant servers 28 and can return all of the addresses (or just selected addresses) to the client when a resolution request 24 is received. The client can then choose a server that is available and functioning, and (ideally) in proximity to the client's location on the network. In most cases, the client software will simply use the first address returned from the resolution mechanism without attempting to verify whether that address is the optimal choice or even accessible to the client.
To reduce the chance that the NS will direct the client to a non-functioning or otherwise unavailable server, some systems make a real-time check at each of the IP addresses to make sure the service is actually available and functioning there. For example, the real-time check can be made by User Datagram Protocol (UDP) or ping (ICMP echo request packets sent to the target; the return packets enable estimates of the round-trip time and packet loss rate between the nodes) messages 37. Although the DNS does not mandate such tests, having the NS do the testing would take advantage of the reliability of the DNS to assure that the client will be served.
In another arrangement, each of the servers is paired with a specialized network server (SNS). The NS used for the given domain name is customized so that it tracks the availability of its paired server. When it receives the domain name resolution request, the SNS uses some method to determine which of the available servers is closest, in the network sense, to the client and returns the IP address of that server to the client. Any SNS for which there was no network path to the client or from the NS will be dropped off the list of possible IP addresses that may be used as NS resolution responses.
The server that provides the desired service may conform to a variety of protocols associated with the service it provides. For a service provided by a Hyper-Text Transfer Protocol (http) server, for example, the request will commonly be expressed as a Uniform Resource Locator (URL), e.g., http://hdl.handle.net/<resourceid>, where hdl.handle.net is the domain name of a known set of servers and <resourceid> denotes a service or other resource available at that any of the servers of that set.